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(54) Architecture for executing applications in a data communications environment 



(57) A service architecture for executing applica- 
tions in a data communications environment comprises 
at least one smart card (1), a user terminal which may 
be a mobile telephone (2) and a server (3) all of which 
are linked via a common interface which comprises II- 
OR The invention combines four existing standards; 



SIM tool kit, WAP, FIPA and CORBA. It enables any ap- 
plication such as E-Mail, for example to migrate and be 
independently executed either on a smart card, mobile 
handset or server. Access to the Internet can be provid- 
ed by WAP layers and applications residing on a smart 
card can launch and run CORBA applications or agent 
applications which are accessed through the HOP. 
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Description 

[0001] This invention relates to an architecture which 
allows applications such as E-Mail to be run over a set 
of devices such as a smart card, a mobile device (tele- 
phone, personal digital assistant), a terminal and a serv- 
er. 

[0002] The architecture proposed herein is modular 
and can run over any subset of devices. It is also generic 
as it relies on standard devices and can evolve towards 
new standards in the future. 

[0003] The current wireless applications protocol 
(WAP) allows access to the Internet from telephones 
and personal digital assistants. The known SIM tool kit 
(subscriber identity module) enables secure transac- 
tions and applications. Agent technology or CORBA 
(common object request broker architecture) introduce 
pervasive architectures and intelligent behaviour. Each 
of these known technologies has its own merits but also 
its weaknesses. For instances, the SIM tool kit facilitates 
security and runs applications but is not able to subcon- 
tract tasks to a server and to enable pervasive comput- 
ing. The SIM tool kit can run applications but they have 
to be designed especially for the SIM tool kit which is 
quite restrictive in size and processing power. 
[0004] WAP brings the Internet to smart telephones 
and personal digital assistants. However, it cannot en- 
sure security of data and the mobile terminal Is restricted 
to visualisation through a browser. Further, WAP does 
not provide a solution for pervasive computing. 
[0005] Agent technology or CORBA allow distribution 
of tasks in a computer environment. However, they rely 
on Internet protocol (IP) connections and use a high 
bandwidth. Agent technology can show intelligent, pro- 
active and autonomous behaviour but needs to run in a 
multi-threaded environment. On the other hand, neither 
agent technology nor CORBA are good media for the 
Internet especially on small devices. In addition, their 
security features are not strong enough to be trusted 
when it comes to money transactions, health data and 
the like. 

[0006] This invention aims to provide an architecture 
capable of supporting the running of Applications over 
a variety of network devices. 

[0007] Accordingly, the present invention comprises 
a service architecture for executing applications in a da- 
ta communications environment, the architecture com- 
prising a smart card, a user terminal and a server, all 
linked via a common interface comprising Internet inter- 
object request broker protocol (HOP). 
[0008] The user terminal may be a personal computer 
or a fixed or mobile telephone handset, for example. 
[0009] In one embodiment, the handset is provided 
with a card interface and the smart card is provided with 
a Java™ card and a communications link therebetween 
is made through a virtual bi-directional bus. The handset 
is further provided with WAP for effecting communica- 
tions with the server which is also provided with WAP. 



[001 0] In a further embodiment, the personal compu- 
ter is provided with a card interface and the smart card 
is provided with a Java™ card and a communications 
link therebetween is made through a virtual bi-direction- 

5 al bus. The personal computer is further provided with 
an Internet protocol (IP) for effecting communications 
with the server which is also provided with a WAP. 
[0011] The smart card may further be provided with 
building blocks comprising a SIM tool kit, a Java™ card 

10 data bus control (JCDBC), a structured query language 
(SQL). 

[0012] The handset may further be provided with 
building blocks comprising Bluetooth, FIPA lite (Foun- 
dation for Intelligent Physical Agents), ORB lite (object 

15 request broker). 

[001 3] The personal computer and server may further 
be provided with building blocks comprising FIPA, ORB. 
[0014] The invention thus proposes an architecture 
that combines four existing standards; SIM tool kit, WAP, 

20 FIPA, and CORBA Into one single architecture which 
makes the link between smart cards, handsets, PC ter- 
minals and servers. 

[0015] The invention has the advantages of enabling 
launch of any application from any device, this encorri- 

25 passes the means for process distribution and allows 
distribution of work over an architecture in order to use 
its resources in an optimal manner. Further, any appli- 
cation can be run on any device. Thus, an operation can 
1 be delegated to other devices by running the application 

30 on such other devices. Applications can be moved dy- 
namically from one device to another and executed lo- 
cally. This permits complete freedom in the deployment 
of applications. 

[0016] This architecture runs in a transparent manner 
35 over the Internet and the wireless environment and pro- 
vides a virtual bus to access a smart card. Therefore, 
any type of network device can communicate within this 
architecture. 

[0017] This architecture allows running of end-to-end 
40 secure applications even in a wireless environment 
(which is not the case for WAP). This architecture also 
allows running of lightweight applications without any 
security. This is especially well suited for mobile termi- 
nals and smart cards. The use of security features can 
45 be determined by the application, how and when need- 
ed. 

[0018] This architecture is optimal in the sense that it 
minimises the code to be developed as it re-uses as 
much as possible existing standards for devices as well 

so as for transport layers. In addition, it is easy to interface 
this architecture with new emerging standards. It can al- 
so run existing standard applications, for example, in a 
preferred embodiment SQL, CORBA, FIPA, WAP and 
SIM tool kit can be used directly. 

55 [0019] Further advantages of the architecture in ac- 
cordance with the invention are the provision of an inte- 
grated set of devices working together in a transparent 
manner and which are accessed through services. This 
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allows access to a database (for example accessed 
through SQL) and permits distribution of tasks in a com- 
puter environment and the running of programs (for ex- 
ample, accessed through CORBA). It can also show 
pro-active and intelligent behaviour agent technology 5 
(for example accessed through FIPA) and can ensure 
end-to-end security (for example accessed through 
smart cards). 

[0020] All these services have to be accessible by 
each network device, and each device has to be able to 
run some of these services. The deployment of the serv- 
ices in the architecture can be done at run time, on de- 
mand of the user, the application or the service provid- 
ers. 

[0021] The architecture minimises the code to be de- 
veloped and indicates which layers have to be devel- 
oped between SIM tool kit, WAP, FIPA and CORBA. This 
common interface is realised with HOP which is a soft- 
ware specified by OMG (object management group), 
[0022] This architecture provides the combination of 
advantages of SIM tool kit, WAP, FIPA and CORBA. Any 
application can migrate and be independently executed, 
either on the smart card, mobile handset or server. 
When security features are an asset, the application can 
be secured through the SIM tool kit and provide an end- 
torend solution. When an access to the Internet is im- 
portant, it can be provided by the WAP layers. Similarly, 
an application residing on the smart card can launch and 
run CORBA applications or agent applications, as they 
can be accessed through HOP. 
[0023] The message transport in the architecture is 
preferably a generic ORB bus. It is transparent to the 
application whatever the device reached, whatever the 
environment. As such, the transport mechanism encom- 
passes the three following functions; transport in the 
wired world (for example through TCP/IP (transmission 
control protocol/Internet protocol)), transport in the wire-, 
less world (for example, through WAP), transport be- 
tween the smart card and the IP or WAP world (for ex- 
ample, by using a virtual bi-directional bus using the SIM 
tool kit). These transport mechanisms are interconnect- 
ed and allow access to any device or service in a trans- 
parent manner. 

[0024] To inter-operate, all the layers of the architec- 
ture have to use a common representation language 
shared by all the applications. In a preferred embodi- 
ment, the HOP data representation (SDL) is shared in 
the whole architecture and allows inter-operability and 
modularity with many existing applications. 
[0025] End-to-end security functions are optional and 
can be used as wished. The encryption algorithms are 
usually embedded in existing smart cards. As the archi- 
tecture is modular, it can host new types of devices pro- 
vided that a connection is made to the existing message 
transport mechanisms. New applications can easily be 
plugged in to this architecture through a common inter- 
connection layer described by an open standard. 
[0026] Some embodiments of the invention will now 



be described by way of example only, with reference to 
the drawings of which; 

Figure 1 is a schematic block diagram of an archi- 
tecture in accordance with the invention for imple- 
mentation in a telecommunications environment, 
Figure 2 is a schematic block diagram of an archi-. 
tecture in accordance with the invention for imple- 
mentation in an Internet environment, 
And Figures 3, 4 and 5 are schematic block dia^ 
grams illustrating execution of tasks performed by 
the architecture of Figure 1 . 

[0027] Figure 1 shows a smart card 1 , a telecommu- 
nications handset 2 and a server 3 all in a telecommu- 
nications environment. The smart card 1 is provided with 
the following building blocks; Java™ card 4, SIM tool kit 
5, a Java™ card data bus control (JCDBC) 6, HOP 7 and 
SQL 8. The handset 2 is provided with the following 
building blocks; a card interface 9, WAP 10, Bluetooth 
1 1 (an open specification for wireless communication of 
data and voice), HOP 12, FIPA lite 13 and ORB lite 14. 
The server 3 is provided with the following building 
blocks; WAP 15, IP 16, MOP 17, FIPA 18 and ORB 19. 
A communication link between the smart card 1 and the 
handset 2 is made through a virtual bi-directional bus 
20. The communication between the handset 2 and the 
server 3 is realised with WAP 10, 15. The link between 
WAP and IP world is already realisable. On top of the 
transport layers at the server 3 and the mobile handset 
2, there is the HOP standard which communicates with 
ORB 1 9 and FIPA 1 8. On the smart card, the HOP layer 
7 allows one to build applications as well as database 
access. 

[0028] The architecture of Figure 1 can realise a pure 
client-server relationship on an object bus through any 
telecommunications network. As such, an application 
can store confidential data on the smart card 1 in a se- 
cure environment. This arrangement is well suited to 
banking applications, for example. 
[0029] HOP is adapted to each part of the architecture. 
Source code of HOP is freely available at the OMG Web 
site and there are several other HOP code providers 
thereby ensuring inter-operation. HOP is basically a thin 
layer, defining seven communication primitives. There 
already exists FIPA agent platforms which are available 
in free software and capable of running on main frames. 
The adaptation of a FIPA agent platform to mobile hand- 
sets called FIPA lite is the subject of the proposal for 
lightweight extensible agent platforms in the EEC's fifth 
framework. An ORB lite version of ORB give benefits of 
access to CORBA through the SIM tool kit. SQL and 
JCDBC in the smart card allow access to databases di- 
rectly from the SIM tool kit. Bluetooth allows communi- 
cation between terminals. 

[0030] Figure 2 shows the smart card 1 and server 3 
operating in an Internet environment which includes a 
personal computer terminal 21 . The smart card 1 and 
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server 3 Include the same building blocks as the archi- 
tecture of Figure 1 with a link between the server 3 and 
the personal computer 21 being based on IP. Thus the 
building blocks provided on the personal computer 21 
comprise iP 22, a card interface 23, HOP 24, FIPA 25 
and ORB 26. A communication link between the smart 
card 1 and the personal computer 21 is made through 
a virtual bi-directional bus 27. Then there is a bridge be- 
tween this virtual bus and IP. On top of the transport lay- 
ers at the server 3 and the personal computer 21 , there 
is the HOP standard 17 and 21 which communicates 
with ORB 1 9 and FIPA 1 8. On the smart card 1 , the HOP 
layer 7 allows building of applications as well as data- 
base access. 

[0031] Three examples of the operation of the archi- 
tecture of Figure 1 will now be described with reference 
to Figures 3, 4 and 5 respectively. In a first example, 
(Figure 3), the smart card 1 wants to perform a search 
in a database residing in the server 3. The operations 
are as follows. A request is sent from the smart card 1 
to the database server The JCDBC and SQL layers al- 
low direct access to the database through SIM tool kit 
5. Next, the request is transported by the generic ORB 
bus over three media, the virtual bi-directional bus 20 
between the smart card 1 and the handset 2, WAP 10 
via a link 29 and finally IP 16. Next, the request 28 is 
transmitted from IP layer 16 to the ORB 1 9 via the HOP 
1 7. Then, ORB 1 9 can execute the database access on 
the server 3. The result 30 of the database search re- 
quest follows the same steps in reverse order. The ac- 
tive building blocks in this example appear hatched in 
the drawing. 

[0032] In a second example (see Figure 4), a lite 
agent system (FIPA lite 1 3) on the handset 2 evolves in 
an insecure environment, browsing the Internet, then 
finds a service the user wants to acquire. The agent 
starts a secure session from end-to-end between a bank 
and the smart card 1 . Once the secure transaction is 
completed, the agent resumes its work. The course of 
actions followed in this example is as follows. Firstly, the 
agent sends a request 31 to the SIM tool kit for opening 
a secure session with the server 3 and suspends its ac- 
tivities. 

[0033] Next, the Java™ card 4 starts a secure session 
by making a connection 32 to the server 3 over the vir- 
tual ORB bus. Then the secure session executes the 
- transaction. The secure session finishes and the agent 
resumes This example could also work In a synchro- 
nous manner where the agent would'not suspend its ac- 
tivities as in the first step above. The active building 
blocks in this example appear hatched in the drawing. 
[0034] A third example is the remote execution of a 
mobile code which utilises a lite agent system on the 
handset. Again, the active building blocks are shown 
hatched. The smart card 1 needs processing power to 
perform a computing-intensive function, say generating 
private keys. The smart card wM transfer the execution 
of its own code to the handset 2 which offers processing 



capabilities. The sequence of action is as follows. The 
smart card 1 send code via a link 33 to the handset 2. 
The mobile handset 2 executes the code it received in 
the ORB environment (ORB lite 14). The results are re- 

5 turned via link 34 to the Java™ card 4 on the smart card 
1 . The scenario in this example is exactly the same if 
the smart card were to execute its software on the server 
3. Any combinations of delegations is possible, for ex- 
ample the smart card 1 delegates to the handset 2 which 

10 jn turn delegates to the server 3. 

[0035] The above examples highlight delegations of 
tasks from the smart card 1 towards the server 3 looking 
for higher processing power. However the architecture 
proposed herein also allows delegating from the server 

is 3 to the smart card 1 . The practical interest of such del- 
egations is to reduce bandwidth by performing tasks di- 
rectly in a handset (which may be a mobile handset) or 
a smart card 1 and to avoid transmission of the data. 
This kind of processing distribution is also of interest for 

20 security Issues. 



Claims 

25 1. A service architecture for executing applications in 
a data communications environment, the architec- 
ture comprising a smart card (1), a user terminal (2) 
and a server (3), all linked via a common interface 
comprising Internet inter-object request broker pro- 
30 tocol (HOP) (7, 12, 17). 

2. A service architecture according to Olaim 1 in which 
the user terminal comprises a telephone handset 
(2). 

35 

3. A service architecture according to Claim 2 in which 
the telephone handset is provided with a card inter- 
face (9) and a wireless applications protocol (10). 

4. A service architecture according to Claims 2 or 3 in 
which the telephone handset (2) further includes a 
lite agent system (13). 

5. A service architecture according to any Claims 2 to 
45 4 in which the telephone handset (2) further in- 
cludes an object request broker (14). 

6. A service architecture according to any of Claims 2 
to 5 in which telephone handset (2) further includes 

so a Bluetooth system (11 ). 

7. A service architecture according to Claim 1 in which 
the user terminal comprises a personal computer 
(21). 



55 

8. A service architecture according to Claim 7 in which 
the personal computer (21) is provided with a card 
interface (23) and an Internet protocol (22). 
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9. A service architecture according to Claims 7 or 8 in 
which the personal computer (21) further includes 
an agent system (25). 

1 0. A service architecture according to any of Claims 7 s 
to 9 in which the personal computer (21) includes 

an object request broker (26). 

11. A service architecture according to any preceding 
Claim in which the smart card (1 ) includes a Java™ 10 
card (4). 

12. A service architecture in accordance with any pre- 
ceding Claim in which the smart card (1 ) includes a 
SIM tool kit (5). is 

13. A service architecture according to any preceding 
Claim in which the smart card (1 ) includes a Java™ 
card data bus control (6). 

20 

14. A service architecture according to any preceding 
Claim in which the smart card (1) is provided with 
structured query language (SQL) (8). 

15. A service architecture according to any preceding 25 
Claim in which the server (3) is provided with a wire- 
less applications protocol (15). 

16. A service architecture according to any preceding 
Claim in which the server (3) includes an agent sys- 30 
tern (18). 

17. A service architecture according to any preceding 
Claim in which the server (3) includes an object re- 
quest broker (19). 35 
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